When more than two people participate in a telecommunications session, the session becomes a conference. An Access Control List (ACL) is typically used to define who is allowed (or not allowed) to join the conference. If a user attempts to join a conference, but the user is not in the ACL then (depending on the conference policy), the conference chair may be consulted whether the user can be accepted to join the conference. Thus, there must be a mechanism to define the Access Control List (ACL) so that user access can be pre-authorized (or denied). It must be possible to add and delete users to/from the ACL. It can be possible to consult a user with appropriate privileges (such as the chair or the owner) when an unknown user tries to join the conference. The chair may accept or deny the join attempt.
Conference participants may have different privileges (i.e. rights). In the simplest case, only two kinds of participants exist: the conference chair (with all the privileges), and normal participants (without any privileges). For example, the following privileges may be supported:                Right to terminate a conference        Right to disconnect participants        Right to manage general conference properties        Right to manage conference access control list (ACL)        Right to manage conference-wide media sessions (e.g. add audio session into conference)        Right to manage other participant's session parameters (such as media)        Right to make real-time authorization (for join attempts)        Right to hand-off all (or some of) the above privileges to another participant        
Some conferences may utilize more complex privilege definition and hierarchy; such as guru-participants having the right to disconnect participants. Therefore, protocol mechanisms must be in place to translate these rights into actions. It must be possible to define different privileges to different participants. It may be possible that different participant levels are defined (e.g. senior-member, panelist), having different rights. Rules should be defined for special cases, such as if the chair leaves suddenly, or the chair tries to take privileges away from all privilege holders. Also, it must be possible to add and delete users into and from the ACL white list (allowed to join) and the ACL black list (not allowed to join). The ACL conflicts must be solved in a well-defined way (e.g. what if user appears both in black list and in white list). It should be possible to use wildcards in ACL (such as *.company.com in white list), and it should also be possible to allow and disallow anonymous and/or hidden users to access the conference.
All of these requirements have not yet been met. These requirements need to be met somehow, and that is the problem to which the present invention is addressed. The present invention is also more generally directed at solving the problem of defining a conferencing policy that will be run when a conference is created.
A typical Session Initiation Protocol (SIP) conference includes a focus, which is defined as an SIP user agent. The focus maintains an SIP signaling relationship with each participant in the conference. The focus is responsible for ensuring, in some way, that each participant receives the media that make up the conference. The focus also implements conference policies, and is a logical role.
A floor is defined as a set of shared resources within a conference; a single conference may have multiple floors. A conference member is a member or participant that has a signaling relationship with the conference focus, and receives one or more of the media streams that are part of the conference.
A conference owner is a privileged user who defines rules for running the conference; by default, the conference creator becomes the owner, but the role can be delegated to another entity. The conference owner may delegate some of these responsibilities to another party. The conference owner does not have to be a member in the conference.
A chair is normally a person who manages one floor by granting, denying, or revoking privileges. The chair does not have to be a member of the conference. The chair is sometimes also referred to as the moderator. Different floors within a conference may have different chairs, and chairs may change during a conference. A conference client will therefore be either an ordinary member, or alternatively will be a chair.
SIP supports the initiation, modification, and termination of media sessions between user agents. These sessions are managed by SIP “dialogs,” which represent an SIP relationship between a pair of user agents. Because dialogs are between pairs of user agents, SIP's usage for two-party communications (such as a phone call), is relatively obvious. Communications sessions with multiple participants (i.e. conferencing) is more complicated.
FIG. 1 depicts the overall conferencing architecture. As mentioned, the “focus” is an SIP user agent that is addressed by a conference URI. The focus maintains an SIP signaling relationship with each participant in the conference. The focus is responsible for insuring, in some way, that each participant receives the media that make up the conference. The focus also implements conference policies. The focus is a logical role. Participants or “clients” are user agents, each identified by a URI, which are connected to the focus for a particular conference. A “conference policy server” is a logical function which can store and manipulate rules associated with participation in a conference. These rules include directives on the lifespan of the conference, who can and cannot join the conference, definitions of roles available in the conference and the responsibilities associated with those roles, and policies on who is allowed to request which roles. The conference policy server is a logical role. A “media policy server” is a logical function which can store and manipulate rules associated with the media distribution of the conference. These rules can specify which participants receive media from which other participants, and the ways in which that media is combined for each participant. In the case of audio, these rules can include the relative volumes at which each participant is mixed. In the case of video, these rules can indicate whether the video is tiled, whether the video indicates the loudest speaker, and so on. A “mixer” receives a set of media streams, and combines their media in a type-specific manner, redistributing the result to each participant. A “conference server” is a physical server which contains, at a minimum, the focus, but may also include a media policy server, a conference policy server, and a mixer. A “floor control server” is another term for “floor controller,” and is responsible for determining which participant(s) in a conference are allowed to speak at any given time, based on participant requests as well as access rules and the chair's decisions.
A floor control protocol is used to convey the floor control messages among the moderator or moderators of the conference, the conference server and the participants of the conference. The floor control protocol does not deal with the conference management such as how to elect the moderator of the conference or how to add users to the conference.
In the past, conferences were created and the policy was statically defined on the server. The simplest approach was to provide offline a conference ID and password to users who are allowed to join the conference. According to that simple approach, there was no real user identification for joining the conference; any user with the correct conference ID and password could join. Although access control lists for conferences have now become a familiar concept, their implementation still fails to satisfy the wide variety of current requirements.